Hablamos de datos evaporados, turbulencias, huracanes, tormentas, cada uno usa su propia metáfora asociada a las nubes, precisamente porque hablamos de computación en la nube, recuperación de desastres, tiempo de inactividad en los centros de datos. Estamos hablando de Amazon Web Service, Aruba, Google Mail, sistemas de almacenamiento en clúster, estamos hablando de datos centralizados, servicios centralizados en centros de datos que se crean para hacer este trabajo, errores humanos, errores de planificación y también la ligereza de los clientes al confiar completamente sin quizás haber leído los contratos SLA, sin haber implementado correctamente su sistema con los servicios prestados por el proveedor, Por último, sin haber valorado los daños económicos y de imagen derivados del tiempo de inactividad, la famosa continuidad del negocio.

Interrupción de AWS

Empecemos por Amazon, como ya se indicó en este otro post el pasado 21 de abril se produjeron problemas en un centro de datos en la zona este-ee.uu. (Virginia), en los servicios fundamentales EC2

y RDS

. Estos han fundamentado algunos servicios sociales famosos de Internet, como Foursquare, Reddit y Quora.

Pero NetFlix, Twilio y otros, aunque utilizaron recursos en la misma zona de disponibilidad, no sufrieron el mismo destino, el propio Reddit volvió a estar en línea casi de inmediato gracias a un sólido contrato de soporte con Amazon que le garantizaba ingenieros dedicados. Amazon nos da un resumen al final de la historia donde ilustra lo que sucedió y cómo manejaron el evento, lo que aprendieron y cómo se moverán en el futuro inmediato para evitar que vuelva a suceder, se disculpan con todos los clientes y hablan sobre el reembolso de créditos para los clientes. Obviamente, el reembolso no se mide en función de la magnitud del daño sufrido, sino que esto depende del tipo de contrato que celebre con el proveedor.

Problemas de sincronización de almacenamiento de EBS

Para el servicio EC2 , el desencadenador era un subconjunto de discos EBS en una zona de disponibilidad. Parece que se han congelado, sin poder leer y escribir, obviamente las instancias que dependían de estos discos también estaban bloqueadas. Deshabilitaron las API de control de este clúster de EBS en esa área afectada. En este punto, Amazon explica brevemente cómo funciona el servicio de disco EBS y su clúster. Como muchos expertos ya habrán adivinado, EBS es un almacenamiento distribuido, que consta de una serie de clústeres que contienen datos en replicación consistente y a nivel de bloque entre sí, y una serie de otros sistemas útiles para coordinar las solicitudes de los usuarios a los nodos. Las réplicas de datos entre los nodos del clúster están garantizadas por una estrategia de conmutación por error rápida punto a punto para desencadenar nuevas réplicas si una deja de estar sincronizada o ya no está disponible. Los nodos están conectados entre sí por dos redes, la primera de banda ancha y la secundaria de menor capacidad utilizada como red de respaldo y expansión para la replicación de datos. La segunda red no se creó para gestionar todo el tráfico de la primaria, sino para proporcionar una conectividad muy fiable entre los nodos.

El problema surgió debido a un error humano durante una actividad de escalado normal de la red primaria de un clúster de EBS, se suponía que el cambio serviría para aumentar su capacidad, pero el tráfico que se debía mover para transferir la actualización se transfirió por error a la red secundaria que no se mantuvo y las réplicas saltaron. Obviamente, el problema del almacenamiento de EBS también ha afectado al servicio de base de datos relacional RDS , que depende totalmente de él

Según un análisis de RightScale habría habido más de 500k volúmenes de EBS afectados, también afirma que un evento de esta magnitud supera los parámetros de diseño, no se puede probar y que no hay un sistema de escala comparable en funcionamiento en ningún otro lugar.

Amazon afirma que realizará una serie de cambios para mejorar y evitar la repetición de este tipo de eventos.

Un comentario interesante de Lew Moorman de Rightscale en una entrevista con el
New York Times
: «La interrupción de Amazon es el equivalente cibernético de un accidente aéreo. Este es un episodio importante con daños generalizados. Pero los viajes aéreos siguen siendo más seguros que los viajes en coche, de forma análoga a que la computación en la nube sea más segura que los centros de datos gestionados por empresas individuales. Todos los días, en empresas de todo el mundo, hay interrupciones de tecnología, cada episodio es muy pequeño, pero puede desperdiciar más tiempo, dinero y negocios».

Lecciones de AWS y los enfoques correctos para usarlo

¿Qué puede hacer el cliente para utilizar correctamente los servicios mencionados para superar los problemas técnicos del proveedor? En primer lugar, el servicio EC2 utilizado de forma sencilla e individual no garantiza una alta disponibilidad, sino que tiene un SLA del 99,95%, lo mismo se aplica a RDS que depende de EC2 y EBS. Pero la propia Amazon comunica que un correcto uso de los servicios conduce a soluciones altamente fiables. Por ejemplo, el uso de varias zonas de implementación (NetFlix usa tres), el uso de instantáneas de EBS crea la capacidad de replicar el volumen en otras zonas de disponibilidad (la instantánea se encuentra físicamente en el sistema S3), realizar copias de seguridad de datos en S3, copias de seguridad e instantáneas de RDS, o incluso habilitar la replicación en varias zonas de disponibilidad (entre diferentes zonas de disponibilidad). Estos son los enfoques que han impedido que ciertos clientes estén desconectados a pesar de los problemas del proveedor.

Aruba

Sobre la base de las declaraciones de Aruba en la siguiente comunicación: http://ticket.aruba.it/News/212/webfarm-arezzo-aggiornamenti-3.aspx

Esta mañana a las h. 04:30, un cortocircuito que se produjo dentro de los armarios de baterías que servían a los sistemas UPS de la granja de servidores Arezzo de Aruba provocó un incendio: el sistema de detección de incendios entró en funcionamiento inmediatamente, que en secuencia apaga el aire acondicionado y activa el sistema de extinción. Como el humo liberado por la combustión de las baterías de plástico invadió por completo las instalaciones de la estructura, el sistema interpretó la persistencia del humo como una continuación del incendio y cortó automáticamente la electricidad.

El sistema UPS debería ser un interruptor de la fuente de alimentación principal, mientras que un error de diseño (error humano) del sistema de ventilación de la sala UPS, provocó el apagado de todos los sistemas, lo que para el mercado italiano significó la desconexión de millones de sitios de clientes. Como dice la propia Aruba en la nota de prensa, este error se solucionará:

Además, aunque es costumbre instalar baterías dentro del centro de datos, para evitar que se repita lo sucedido, a partir de hoy las baterías del centro de datos de Arezzo y todos los demás centros de datos del Grupo Aruba se instalarán en salas especiales, externas y separadas de la estructura principal.

Google Gmail

En el caso de la interrupción de algunos clientes de correo de Gmail el pasado mes de febrero, como se comunicó en http://static.googleusercontent.com/external_content/untrusted_dlcp/www.google.com/it//appsstatus/ir/nfed4uv2f8xby99.pdf, la interrupción fue causada por un error introducido inadvertidamente en una actualización de software (error humano), y para evitar problemas de integridad de los datos que inhabilitaran el acceso a Google Apps para el número de clientes afectados, el equipo de ingeniería tuvo que restaurar los buzones de correo de las cintas de copia de seguridad, confirmando que las copias de seguridad en cinta siguen en uso y siguen siendo fiables.

Conclusiones

A pesar de estos incidentes, como dice Lew Moorman en la entrevista del NYT, los grandes centros de datos gestionados por estas grandes entidades son siempre más seguros que las soluciones que podrían adoptar las pequeñas y medianas empresas.

En su lugar, la discusión debería trasladarse a un tema muy complejo que parte de la siguiente observación:

porque Facebook, Google y Amazon construyen servidores (Facebook y Google específicamente), centros de datos (ver Facebook OpenCompute Project), modifican o crean proyectos de software de código abierto para sus propias necesidades (ver Bigtable de Google), por ejemplo los sistemas de almacenamiento S3 EBS (parecen usar DRDB), SDB, donde el corazón palpitante son las baterías de servidores clásicos pero potentes, Sistemas de red dedicados que replican datos entre los numerosos nodos, es decir, soluciones de software propietario o modificaciones de proyectos de código abierto nacidos en alguna universidad del mundo y tal vez aún en desarrollo en alguna parte mundial.

la pregunta es provocadora para los proveedores de maxi sistemas (IBM, HP, Dell, etc), pero la respuesta podría estar en las siguientes publicaciones antiguas ( Tecnología Isilon, EMC compra Isilon, HP compra LefHand, y otras adquisiciones recientes), es decir, los grandes proveedores hace solo unos años comenzaron a entender la necesidad de especializarse en sistemas de almacenamiento distribuido en clúster, porque solo estos sistemas tienen la capacidad de responder a grandes cantidades de datos y grandes necesidades de ancho de banda y acceso simultáneo, además de las enormes necesidades de Amazon, Google, Facebook inclina la balanza económica hacia soluciones abiertas o propietarias en comparación con los costos de licencia y soporte que tendrían a través de los proveedores del pasado.

En definitiva, la mayoría de las soluciones de software o hardware de los servicios que utilizamos y utilizaremos cada vez más, pertenezcan o no al paradigma de la computación en la nube, son sistemas que, por su tamaño y alcance, nunca serán probados de forma efectiva para evitar el desastre.